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ABSTRACT 



A software package manager uses a distribution unit con- 
taining components for a software package and a manifest 
file that describes the distribution unit to manage the 
installation, execution, and uninstallation of software pack- 
ages on a computer. Information in the manifest file per- 
taining to a software package is stored in a code store data 
structure upon installation of the package. The manifest file 
also contains information that permits the software package 
manager to resolve any software dependencies upon instal- 
lation. The software package manager uses the code store 
data structure to locate the required components when the 
software is executed and to remove the components appro- 
priately when the software is uninstalled. 
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SOFTWARE PACKAGE MANAGEMENT component in a software program requires the presence of 

another to operate. If a user downloads software from a Web 

RELATED APPLICATION page, the user may discover that the program requires an 

__. . . TTP . 4 4 . c external library which necessitates another network session 

5$^^^ SLSttSLT mam,lUy instaU 1,10 Ubmy before 

Dec. 12, 1996, and assigned to the assignee of the present „ . . . , , 

! ' Software programs written in the popular platform - 

W independent Java language require that the Java classes be 

COPYRIGHT NOTICE/PERMISSION 10 "packaged" for distribution but the package does not contain 

persistent information so once Java software is installed on 
A portion of the disclosure of this patent document a c ij ent computer, all information about it is lost. It is 
contains material which is subject to copyright protection. impossible to tell what the version number is, where it came 
The copyright owner has no objection to the facsimile &onij or w ^ l0m the author is. Additionally, the current 
reproduction by anyone of the patent document or the patent J5 nctW ork distribution methods make it difficult to digitally 
disclosure as it appears in the Patent and Trademark Office sign a Java pac kag e f or security purposes, 
patent file or records, but otherwise reserves all copyright More blems ^ when a ^ wants lo execute an 
rights whatsoever. The following notice applies to the soft- application which dcp ends on both native code components 
ware and data as described below and in the drawing hereto: ^ Jaya onents since me distribution methods are 
Copyright© 1997, Microsoft Corporation, All Rights ^ comple tely different. Finally, once the software is down- 
Reserved, loaded and successfully installed on the client computer, no 
FIELD OF THE INVENTION mechanism exists to track all of the components so that older 

versions can be easily superceded when newer version are 

This invention relates generally to software distribution, available or that all the related components can be readily 

and more particularly to the management of software pack- 25 uninstalled when necessary. 

ages after distribution. Therefore, there is a need for a software distribution and 

~ . ™™ rtT ,™ m ^ __ rT , VT ^ rT ^ VT tracking mechanism that handles cross-platform software, 

BACKGROUND OF THE INVENTION spedfi * ^ ampoaaA d6peDdencies , a „ d is applicable to 

Historically, the primary medium for software distribution 3Q both the older distribution media as well as to the network 

has been either the traditional floppy disk or the more recent distribution paradigm. 

compact disc (CD-ROM). However, more and more indi- ei „„. ADV „ INRa:WTmM 

viduals are acquiring software by downloading it from SUMMARY OF THE INVENTION 

remote server computers connected to the client computers The above-mentioned shortcomings, disadvantages and 

through the Internet. Additionally, companies and organiza- 35 problems are addressed by the present invention, which will 

tions are distributing software to their users across their local be understood by reading and studying the following speci- 

area networks. Hie physical medium is the network cable fication. 

itself and the supporting communication hardware, a fixed ^ software package manager uses a distribution unit 
cost associated with the establishment of the network. containing components for a software package and a mani- 
Therefore, distributing and installing software over an exist- 4Q f est gi e that describes the distribution unit to manage the 
ing network bypasses the cost overhead of producing CDs or installation, execution, and uriinstallation of software pack- 
floppy disks. ages on a computer. For installation, the package manager 

In addition, using the network as the distribution medium acquires the manifest file and parses it to learn if the 

profoundly reduces the software's total cost of ownership to software package depends on any additional components, 

an extent that cannot be achieved by CDs or floppies even 45 The package manager resolves any dependencies by aoquir- 

when the media cost almost nothing to manufacture. Soft- ing a distribution unit containing the needed component and 

ware distribution via CDs and floppies obey the "pull" installs the dependency's distribution unit as described 

paradigm, where every action is user-initiated. Distribution below. Because dependencies can be nested within 

over the network has the ability to apply a "push" paradigm dependencies, the package manager recursively processes 

which provides three main benefits. 50 all the dependencies before finishing the installation of the 

First, the installation is "hands-free" in that the user does software package that depends upon the additional compo- 

nol have to manually install the software. Second, the nents. 

software can be easily and timely upgraded from a desig- The software package manager acquires the distribution 

nated location because the burden of upgrading is borne by unit and extracts the components in the distribution unit into 

the software itself. Third, because different types of com- 55 a directory on the computer. The package manager causes 

puter hardware and operating systems can connect to a the operating system of the computer to install the software, 

common network, software distributed over the network can The package manager then updates a code store data stmc- 

be made lo work across platforms or intelligent so that only hire with information in the manifest file. The fields in the 

the correct version of platform-specific software is pushed code store data structure contains such information as the 

down to the user. 60 name and version of the distribution unit, a list of the 

However, current methods of software distribution over a components and their location on the computer, and the 

network do not fully exploit the benefits. Existing distribu- source of the distribution unit Additional fields in the code 

tion of platform -specific, or "native code," software relies on store data structure can also contain a component version, a 

installation file formats that are hard to create, not component data type, and a digital signature if one was 

extensible, and specific to a particular operating system, 65 affixed to the distribution unit. 

Although most current software is written in modules, there During the installation, the package manager can option- 
is no current mechanism that handles the situation where one ally scan the code store data structure to determine if a 
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component to be installed already exists on the computer FIG. 4 is a diagram of an exemplary embodiment of an 

and updates the code store data structure with the location of entry in a code store data structure suitable for use by the 

the later version of the component. methods shown in FIGS. 3 A, 3B and 3C. 

When a user requests execution of software the package DETAILED DESCRIPTION OF THE 

manager uses the code store data structure to locate the S INVENTION 
appropriate components for the operating system to use. 

When the user requests the uninstallation of a software la the following detailed description of exemplary 

package, the package manager deletes the appropriate com- embodiments of the invention, reference is made to the 

ponents from the computer and updates the code store data accompanying drawings which form a part hereof, and in 

structure accordingly. 10 which is shown by way of illustration specific exemplary 

The manifest file and distribution unit optionally are embodiments in which the invention may be practiced, 

combined into a distribution unit file. These embodiments are described in sufficient detail to 

The manifest file format is common across all types of enable those skilled in the art to practice the invention, and 

code and operating systems and easily extended to embrace it is to be understood that other embodiments may be utilized 

new code types as they arise. The manifest file and distri- 15 and that logical, mechanical, electrical and other changes 

bution unit can be stored on all types of media from may be made without departing from the sprat or scope or 

traditional magnetic and optical disks to networked servers. P^sent invention. The following detailed description is, 

The distribution units for dependencies do not have to reside therefore, not to be taken in a limiting sense, and the scope 

on the same type of media as the distribution unit or the of the present invention is defined only by the appended 

manifest file that refers to the dependency. More than one 20 claims. 

distribution unit can be resident in a distribution unit file and The detailed description is divided into five sections. In 

a distribution unit file can contain a mixture of distribution the first section, the hardware and the operating environment 

units containing different code types. in conjunction with which embodiments of the invention 

Thus, the software package manager, the manifest file, the may be practiced are described. In the second section, a 

distribution unit and the code store data structure of the system level overview of the invention is presented. In the 

present invention solve the problems with existing distribu- third section, methods for an exemplary embodiment of the 

tion mechanisms. The manifest file is not particular to a invention are provided. In the fourth section, a particular 

particular code type or operating system and allows for the Open Software Description implementation of the invention 

specification of nested software dependencies. Because the 3Q is described. Finally, in the fifth section, a conclusion of the 

manifest file contains the location of the distribution units detailed description is provided, 

for any dependencies the software package manager can and Environment 

acquire and install the dependencies without requiring r ° 

manual intervention by the user. Different types of distribu- FIG. 1 is a diagram of the hardware and operating 

tion units can be mixed in a distribution unit file so that a 35 environment in conjunction with which embodiments of the 

single mechanism is used to acquire and install all types of invention may be practiced. The description of FIG. 1 is 

code. intended to provide a brief, general description of suitable 

The code store data structure maintained by the software computer hardware and a suitable computing environment in 

package manager contains information about the installed conjunction with which the invention may be implemented, 

software such as version and installation location, and is 40 Although not required, the invention is described in the 

used to resolve version discrepancies among software pro- general context of computer-executable instructions, such as 

grams that share components. The code store data structure program modules, being executed by a computer, such as a 

is used by the package manager to locate necessary com- personal computer. Generally, program modules include 

ponents when the software is executed so that a component routines, programs, objects, components, data structures, 

stored in one directory can be readily shared by software 45 etc., that perform particular tasks or implement particular 

programs with components in different directories. Finally, abstract data types. 

the code store data structure eases the uninstallation process Moreover, those skilled in the art will appreciate that the 
by centralizing all the information about installed compo- invention may be practiced with other computer system 
nents. configurations, including hand-held devices, multiprocessor 
The present invention describes systems, clients, servers, 50 systems, microprocessor-based or programmable consumer 
methods, and computer-readable media of varying scope. In electronics, network PCs, minicomputers, mainframe 
addition to the aspects and advantages of the present inven- computers, and the like. The invention may also be practiced 
tion described in this summary, further aspects and advan- in distributed computing environments where tasks are 
tages of the invention will become apparent by reference to performed by remote processing devices that are linked 
the drawings and by reading the detailed description that 55 through a communications network. In a distributed corn- 
follows, puling environment, program modules may be located in 

both local and remote memory storage devices. 

BRIEF DESCRIPTION OF THE DRAWINGS ^ and environm6Qt of 

FIG. 1 shows a diagram of the hardware and operating FiG. 1 for implementing the invention includes a general 

environment in conjunction with which embodiments of the 60 purpose computing device in the form of a computer 20, 

invention may be practiced; including a processing unit 21, a system memory 22, and a 

FIGS. 2A, 2B and 2C are diagrams illustrating a system- system bus 23 that operatively couples various system 
level overview of an exemplary embodiment of a package components, including the system memory 22, to the pro- 
manager of the invention; cessing unit 21. There may be only one or there may be more 

FIGS. 3A,3B,3C and 3D are flowchart of methods to be 65 than one processing unit 21, such that the processor of 

performed by a client according to an exemplary embodi- computer 20 comprises a single central-processing unit 

ment of the package manager of the invention; and (CPU), or a plurality of processing units, commonly referred 
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to as a parallel processing environment. The computer 20 network interface or adapter 53, which is one type of 

may be a conventional computer, a distributed computer, or communications device. When used in a WAN-networking 

any other type of computer; the invention is not so limited. environment, the computer 20 typically includes a modem 

The system bus 23 may be any of several types of bus 54, a type of communications device, or any other type of 

structures including a memory bus or memory controller, a 5 communications device for establishing communications 

peripheral bus, and a local bus using any of a variety of bus 0 vcr the wide area network 52, such as the Internet. The 

architectures. The system memory may also be referred to as modem 54, which may be internal or external, is connected 

simply the memory, and includes read only memory (ROM) to mc sys tem bus 23 via the serial port interface 46. In a 

24 and random access memory (RAM) 25. A basic input/ networked environment, program modules depicted relative 

output system (BIOS) 26, containing the basic routines that 10 to ^ personal computer 20, or portions thereof, may be 

help to transfer information between elements within the stored m ^ re(note memorv g^ge device. It is appreciated 

computer 20, such as during start-up, is stored m ROM 24. mat mc Qetwork COQnections ^ owu arc exemplary and other 

The computer 20 further includes a hard disk drive 27 for q{ ^ coramumcations device s for establishing a 

reading from and writing to a hard tek not shown a communications Unk betweeD me ^utcrs may be used, 

magnetic disk drive 28 for reading from or writing to a .... 

removable magnetic disk 29, and an optical disk drive 30 for 15 The hardware and operating environment m conjunction 

reading from or writing to a removable optical disk 31 such with which embodiments of the mvention may be practiced 

as a CD ROM or other optical media. has been described. The computer in conjunction with which 

The hard disk drive 27, magnetic disk drive 28, and embodiments of the invention may be practiced may be a 

optical disk drive 30 are connected to the system bus 23 by conventional computer, a distributed computer, or any other 

a hard disk drive interface 32, a magnetic disk drive inter- 20 type of computer; the invention is not so limited. Such a 

face 33, and an optical disk drive interface 34, respectively. computer typically includes one or more processing units as 

The drives and their associated computer-readable media its processor, and a computer-readable medium such as a 

provide nonvolatile storage of computer-readable memory. The computer may also include a communications 

instructions, data structures, program modules and other device such as a network adapter or a modem, so that it is 

data for the computer 20. It should be appreciated by those 25 able to communicatively couple to other computers, 
skilled in the art that any type of computer-readable media 

which can store data that is accessible by a computer, such System Level Overview 

as magnetic cassettes, flash memory cards, digital video t , c . 

disks/Bernoulli cartridges, random access memories Asystcm level ovemew of the operator, of an exemplary 

(RAMs), read only memories (ROMs), and the like, may be 30 embodiment of the mvention is described by reference to 

used in the exemplary operating environment. FIGS. 2A, 2B and 2C. The exemplary embodiment is 

Anumberofprogrammodulesmaybestoredonthehard implemented in an wide- area networking envu-onment 52 

disk, magnetic disk 29, optical disk 31, ROM 24, or RAM havm e a server computer, such as remote computer 49 and 

25, including an operating system 35, one or more applica- * ™? « com P» te i> ^ch as local computer 20, all of 

tion program^ 36, other program modules 37, and program 35 wlu * Me shoWn 1D RG 1 ^ deSC * cd m ^ 

data 38. A user may enter commands and information into section. 

the personal computer 20 through input devices such as a Fred's Software Company has written a software package 
keyboard 40 and pointing device 42. Other input devices named "CoolestApp" that runs as a "plug-in application" in 
(not shown) may include a microphone, joystick, game pad, a World Wide Web browser, such as Microsoft Internet 
satellite dish, scanner, or the like. These and other input 4Q Explorer 4. A plug-in application is often employed to 
devices are often connected to the processing unit 21 provide additional capabilities, such as multimedia or inter- 
through a serial port interface 46 that is coupled to the active controls, to browsers. One type of control application 
system bus, but may be connected by other interfaces, such is that written to conform with Microsoft's ActiveX speci- 
as a parallel port, game port, or a universal serial bus (USB). fications. The plug-ins are usually written in object-oriented 
A monitor 47 or other type of display device is also 45 languages such as C++ or Java and are typically used on 
connected to the system bus 23 via an interface, such as a Web pages. The user may be prompted to download the 
video adapter 48. In addition to the monitor, computers plug-in or it may be automatically downloaded when 
typically include other peripheral output devices (not needed. 

shown), such as speakers and printers. Referring to FIG. 2A, Fred's Software Company wants to 
The computer 20 may operate in a networked environ- so distribute the CoolestApp over the Internet from Fred's 
ment using logical connections to one or more remote Software Company's Web server 201 to a user's computer 
computers, such as remote computer 49. These logical 203. Fred's Software Company logically groups the corn- 
connections are achieved by a communication device ponents for the CoolestApp together into a "distribution 
coupled to or a part of the computer 20; the invention is not unit" 209. The components can include platform-specific 
limited to a particular type of communications device. The 55 compiled binary files such as dynamic linking library (.dll) 
remote computer 49 may be another computer, a server, a files used by the Microsoft Windows family of operating 
router, a network PC, a client, a peer device or other systems, Java bytecode (.class) files, or files that contain 
common network node, and typically includes many or all of optional installation instructions for how to use certain 
the elements described above relative to the computer 20, components contained in the distribution unit, for example, 
although only a memory storage device 50 has been illus- 60 ActiveX controls may need to be registered before use. The 
trated in FIG. 1. The logical connections depicted in FIG. 1 distribution unit 209 can be a separate file or can be a portion 
include a local-area network (LAN) 51 and a wide-area of a "distribution unit file" 205 as explained below, 
network (WAN) 52. Such networking environments are Fred's Software Company also creates a "manifest" file 
commonplace in offices, enterprise- wide computer 207 describing the CoolestApp. The CoolestApp manifest 
networks, intranets and the Internet. 65 file 207 contains information about CoolestApp, including 
When used in a LAN-networking environment, the com- the name of the CoolestApp distribution unit 209, the 
puter 20 is connected to the local network 51 through a version number of the software package (all components in 
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the distribution unit 209 have the same version number in 
this embodiment), and the operating systems under which 
the CoolestApp executes. Fred's Software Company 
bundles the CoolestApp distribution unit 209 and manifest 
file 207 into a distribution unit file 205 for storage on the 
server 201. 

The names of other files in the distribution unit file 205, 
such as a text file containing licensing information or a 
"readme" file containing special instructions for the software 
package, are listed in the manifest file 207. The manifest file 
207 also contains entries for software that is required to run 
CoolestApp but which is not included in the distribution unit 
file 205. Such required software represent "dependencies" 
and frequently include such items as language libraries and 
common object class libraries. A dependency can also be 
another software package. The manifest file 207 provides the 
ability to describe the software dependencies in a recursive 
tree format, also known as a "directed graph." 

In the present example, CoolestApp is an enhanced ver- 
sion of a software program named "CoolApp" previously 
distributed by Fred's Software Company. Rather than com- 
pletely rewriting CoolestApp, Fred's Software Company 
used the CoolApp components as a base and created addi- 
tional components for the new features in CoolestApp. In the 
interest of minimizing download time, Fred's Software 
Company does not include the original components for 
CoolApp in the CoolestApp distribution unit 205. Instead 
Fred's Software Company inserts a dependency entry in the 
manifest file 205 which directs a user's browser to the 
location on Fred's Software Company server 201 holding 
the distribution unit file 215 for CoolApp as illustrated in 
FIG. 2B. 

The browser begins the installation of the CoolestApp 
software package to the local computer by downloading the 
CoolestApp distribution unit file 205. A software package 
manager 211 running in the underlying operating system on 
the user's computer 203 extracts the manifest file 207 from 
the distribution unit file 209 and accesses an installed 
package database 213 to determine that Fred's Software 
Company's CoolestApp is not already installed. The depen- 
dency entry in CoolestApp manifest file 207 alerts the 
package manager 211 that the CoolestApp depends on 
Fred's Software Company's CoolApp. The package man- 
ager 211 determines that CoolApp has not been previously 
installed and directs the browser to download the CoolApp 
distribution unit file 215 from the server location specified in 
the dependency entry. 

Once the CoolApp distribution unit file 215 has been 
downloaded to the user's computer 203, the package man- 
ager extracts the CoolApp manifest file 217 and determines 
that CoolApp does not have any dependencies. The package 
manager 211 creates a private directory 221 for Fred's 
Software Company applications, named FSC, extracts the 
CoolApp components from the distribution unit 219 into the 
FSC directory, and calls the underlying operating system 
installation facility to install the CoolApp components. The 
package manager 211 registers the CoolApp components in 
the installed package database 213 when the installation is 
successful. 

Referring to FIG. 2C, the package manager 213 extracts 
the CoolestApp components from the CoolestApp distribu- 
tion unit 209 to the FSC directory 221, calls the installation 
facility, and registers the CoolestApp components in the 
installed package database 213. The browser now can run 
the CoolestApp helper application from the FSC directory 
221. 



If the user downloads additional Fred's Software Com- 
pany applications that depend upon the components in either 
CoolApp or CoolestApp, the package manager 211 will use 
the already installed components to satisfy any dependencies 

5 that reference installed software package unless the addi- 
tional applications require versions later than that installed. 

If after running the CoolestApp helper application, the 
user decides that CoolestApp is not needed, the user 
employs the underlying operating systems uninstall facility 

10 to uninstall CoolestApp. The uninstall facility invokes the 
package manager 211 which determines if the CoolApp and 
CoolestApp components are being used by other applica- 
tions and deletes the software packages from the FSC 
directory 221 if not. The package manager 211 also deletes 

15 the package entries from the installed package database 213 
when the packages have been deleted from the FSC direc- 
tory 221. 

The system level overview of the operation of an exem- 
plary embodiment of the invention has been described in this 

20 section of the detailed description. The package manager 
and its supporting files have been described in relation to 
installing a software package having a single dependency. 
While the invention is not limited to any particular distri- 
bution media, for sake of clarity a simplified version of 

25 Internet software distribution has been described. 

Methods of an Exemplary Embodiment of the 
Invention 

In the previous section, a system level overview of the 
30 operation of an exemplary embodiment of the invention was 
described. In this section, the particular methods performed 
by a client or local computer of such an exemplary embodi- 
ment are described by reference to a series of flowcharts. 
The methods to be performed by the client computer con- 
35 stitute computer programs made up of computer-executable 
instructions. Describing the methods by reference to a 
flowchart enables one skilled in the art to develop such 
programs including such instructions to carry out the meth- 
ods on suitable computerized clients (the processor of the 
40 clients executing the instructions from computer-readable 
media). 

The software package manager of the present invention is 
described as providing three major functions to the runtime 
environment of the local computer on which it runs as 

45 illustrated in FIGS. 3A-3D. It manages the installation of 
software packages, it locates necessary components when 
software is executed, and it supports the uninstallation of 
software. The package manager uses the installed package 
database, also called a "code store" data structure, to track 

50 components of software packages that have been installed 
on the local computer. One of skill in the art will, upon 
reading the following description of the code store data 
structure, recognize that any type of organized data 
structure, including various type of data bases, is suitable for 

55 use with the package manager. 

As in the exemplary embodiment described in the previ- 
ous section, the manifest file contains dependency entries 
specifying locations of distribution units containing required 
software components. The distribution unit file is suitable 

60 for distributing software packages on traditional media, such 
as CD-ROM or floppy disk, as well as over a wide area 
network, such as the Internet. The package manager extracts 
the manifest file and the distribution unit from the distribu- 
tion unit file. In an alternate embodiment, the distribution 

65 unit and the manifest file can be stored separately on a 
network and the manifest file contains the network location 
of its corresponding distribution unit. 
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Installation 

Referring first to FIGS. 3A and 3B, a flowchart of 
methods to be performed by a client according to an exem- 
plary embodiment of the invention when installing new 
software is shown. This method is inclusive of the steps or 
acts required to be taken by the package manager. 

When the distribution unit file for a software package is 
loaded onto a computer for installation, the software pack- 
age manager running in the computer acquires the manifest 
file for processing (step 301). In an embodiment in which the 
manifest file is distributed in a distribution unit file, the 
package manager acquires the distribution unit file and 
extracts the manifest file from the distribution unit file. The 
package manager checks the name and version of the 
software package contained in the manifest file against the 
code store data structure to determine if the software pack- 
age has already been installed (step 303). If so, the package 
manager exits (step 321) 

If the software package is not installed, the package 
manager checks the manifest file to determine if the software 
package requires the installation of other software compo- 
nents (dependencies) not supplied as part of the distribution 
file unit (step 305) before installing the software package 
from the distribution unit. Such is frequently the case when 
a software package is written in a common programming 
language such as Java or C++ which depend on object class 
or language libraries being present. 

If there are dependencies, the package manager checks the 
code store data structure to determine if the dependencies 
are installed on the local computer (step 327). If not, the 
package manager uses information stored in the manifest file 
about the dependencies to locate a source for the dependen- 
cies. The package manager then acquires a dependency from 
the source specified in the manifest file (step 329). In one 
embodiment, the source is a remote server designated by a 
uniform resource locator (URL) path name. In an alternate 
embodiment, the source is a server on a local area network 
and the path name is a network drive. 

After acquiring the dependency from the source, the 
package manager installs the dependent software compo- 
nents on the local computer. The installation of the depen- 
dent components is identical to the installation process for 
the original software package which will be described in 
detail below in conjunction with steps 307 through 325. 
Because each dependency can itself include dependencies, 
the package manager will install all the nested dependencies 
prior to finishing the installation of the original software 
package. 

Once all the dependencies are installed, the package 
manager determines if a directory for the software package 
exists (step 307) and creates one if it does not (step 309). The 
package manager assigns the directory a unique name that 
has a high probability of being different for every computer 
on which the software package is installed. In one 
embodiment, the unique name is generated using a standard 
hashing algorithm having the software package name as 
input. 

The package manager extracts the components for the 
software package from the distribution unit file into the 
directory (step 311). In one embodiment, the components are 
gathered into an uncompressed "zip" formatted data file 
which contains a directory of the files within it. Other 
embodiments which use similar file structures to group the 
components together with a directory structure will be 
readily apparent to one skilled in the art The package 
manager then invokes the installation facility provided by 
the operating system to install the components (step 313). 
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When the installation is successful (step 315), the package 
manager updates the code store data structure with the 
information contained in the manifest file (step 317 and FIG, 
3B). 

The package manager creates an entry , in the code store 
data structure for the software package that includes the 
name of the software package, the version number, and the 
name of the directory (step 331). The names of the compo- 
nents in the software package are stored in the correspond- 
ing software package entry in code store data structure (step 
333). 

In one alternate embodiment shown in FIG. 3B, as part of 
the update process for the code store data structure, the 
package manager scans the code store data structure to 
determine if any of the components in the software package 

15 are shared with other software packages registered in the 
code store data structure (step 335). If so, the package 
manager performs one of three basic actions depending on 
the version information stored in the code store data base 
entries for the component (step 337). 

20 If the newly stored component is a newer version of the 
previously stored component (step 339) and the code store 
data structure entry for the previously installed software 
package that references the older version does not indicate 
it is version dependent (step 341), the package manager 

25 removes the older version from the directory in which it is 
stored (step 343) and updates the code store data structure 
entry for the previously installed software package to point 
to the newer version (step 345). If there is a version 
dependency noted, the package manager leaves the older 

30 version in the directory (step 347). 

If the newly stored component is older that the previously 
stored component (step 349) and the software package does 
not indicate a version dependency (step 351), the package 
manager removes the older version from the newly created 

35 directory (step 353) and updates the code store data structure 
entry for the newly installed software package to point to the 
newer version (step 355). As before, if there is a version 
dependency noted, the package manager does nothing to the 
older version (step 347). 

40 If the components are the same version, the package 
manager chooses one to remove from its directory (step 359) 
and updates the corresponding entry to point to the other 
component (step 361). 

In the embodiment in which the components are stored in 

45 an uncompressed zip file, or the like, the package manager 
uses the file directory to find the component to be deleted 
within the file in the appropriate directory. The package 
manager can, alternately, actually delete the component 
from the file and update the file directory or mark the 

50 component entry in the file directory as deleted depending 
on the particular file structure employed to hold the com- 
ponents. 

In an alternate embodiment, the package manager does 
not attempt to determine if there are mismatched versions 
55 installed and each software package uses the version of the 
component that is indicated by its entry in the code store data 
structure. 
Execution 

Referring next to FIG. 3C, a flowchart of a method to be 
60 performed by a client computer according to an exemplary 
embodiment of the invention when a software package 
registered through the package manager is executed in the 
runtime environment is shown. This method is inclusive of 
the steps or acts required to be taken by the software package 
65 manager. 

When the user requests execution of the software 
package, the runtime environment invokes the package 
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manager (step 370) to locate the components necessary to 
run the software. The package manager matches the soft- 
ware package name to the corresponding entry in the code 
store data structure (step 371) to determine the directory, or 
directories, holding the components (step 373). In the 
embodiment in which the components are stored in an 
uncompressed zip file, or the like, the package manager uses 
the directory to find the particular components within the 
file. The package manager returns the location of the com- 
ponents to the runtime environment (step 375). 
Uainstall 

Finally, referring to FIG. 3D, a flowchart of a method to 
be performed by a client computer according to an exem- 
plary embodiment of the invention when a software package 
registered through the package manager is uninstalled is 
shown. This method is inclusive of the steps or acts required 
to be taken by the software package manager. 

When the user wants to uninstall a software package from 
the local computer, a standard uninstall routine provided by 
the runtime environment invokes the package manager to 
update the code store data structure accordingly (step 380). 
The package manager removes the corresponding software 
package entry in the code store data structure (step 381). The 
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signed. As well be familiar to one of skill in the art, the 
digital signature itself can contain security attributes about 
the package. The security attributes can be used by the 
package manager to prevent versions updates from a source 
other than the signer. Furthermore, a vendor may include 
software packages from third parties as dependencies in the 
distribution unit and the package manager uses the digital 
signatures on each dependent package to direct the corre- 
sponding components into different local directories. 

In one embodiment of the code store data structure 
implemented in the Microsoft Windows environment, the 
system registry file is used as the repository for the code 
store entries and the package manager accesses the entries 
through the standard registry interface provided by the 
operating system. 
Summary 

The particular methods performed by the package man- 
ager of an exemplary embodiment of the invention have 
been described. The method performed by the package has 
been shown by reference to flowcharts including the steps 
from 300 to 355 during installation of a software package, 
the steps 370 to 375 during execution of a software package, 
and steps 380-385 during uninstallation of a software pack- 
age. Additionally, an exemplary embodiment of a code store 



package manager does not delete a component from the 

directory unless no other installed software package refer- 25 data structure has been described 
ences it (step 383). 

In one embodiment, the package manager scans every 
entry in the code store data structure to determine if another 
the entry for another software package references the local 
directory holding the component in question. In a first 30 
alternate embodiment, the package manager creates and 
maintains a tree structure of all shared components, so it can 
quickly determine if the component is shared with another 
software package. In a second alternate embodiment, the 



Open Software Description Implementation 

In this section of the detailed description, a particular 
implementation of the invention is described that formats the 
manifest file using an Open Software Description (OSD) 
format. OSD specifies a vocabulary used for describing 
software packages and their dependencies for client com- 
puters which is a subset of the Extensible Markup Language 



component is not deleted at the time the software package is 35 (XML). XML is similar to the Hypertext Markup Language 

(HTML) used to write Web pages and provides a general 
method of representing structured data in the form of lexical 
trees. Using the XML model, markup tags in the OSD 
vocabulary are represented as elements of a tree. The three 
basic relationships between elements are "parent-of," 
"child-of," and "sibling-of." Distant relationships can be 
formed from recursive applications of the three basic ones. 
The basic XML elements that compose the OSD format are 
shown in Table 1 below. Additional information on the OSD 
vocabulary can be found in the Specification for the Open 
Software Description (OSD) Format published on Aug. 11, 
1997, and available for download from either Microsoft 
Corporation or Marimba, Inc. 
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uninstalled but instead a "garbage collection" routine is 
periodically run by the package manager. The garbage 
collection routine uses the code store data structure to 
determine if a component is referenced by any of the 
software packages installed on the local computer. Those 
components which are not referenced are then deleted. 
Code Store Data Structure 

FIG. 4 illustrates an exemplary embodiment of an entry in 
the code store data structure 400 suitable for use by the 
methods of the exemplary embodiments of the package 
manager described above. Each entry contains, at a 
minimum, five fields: a name field 401 for the distribution 
unit, a version field 403 for the distribution unit, a compo- 
nent field 405 that contains a list of the components in the 
distribution unit, a location field 407 that contains the 50 
location of the components on the client computer, and a 
source field 409 that contains a pointer to the source of the 
distribution unit, such as a URL for a downloaded distribu- 
tion unit. If a component is a platform-specific ("native 
code") file, such as a Microsoft Windows DLL, the file name 55 
is the component is stored in the component field. If a 
component is a package of Java classes, the component field 
contains the name of the Java package. In the case of a Java 
package, the code store entry has the following additional 
fields: a component version field 411 (which may be differ- 60 
ent from the version of the distribution unit; both are used by 
the package manager in resolving version dependencies), 
and a component type field 413 that indicates what type of 
Java classes the package contains, i.e., system, application, 
etc., both shown in phantom in FIG. 4 An optional data 65 
signature field 415, also shown in phantom, contains a child of 
digital signature affixed to the distribution unit, if it was 



TABLE 1 



Element 
Content 
Child of 
Element 
Attributes 



Child of 
Element 
Attributes 



ABSTRACT 
<string> 
SOFTPKG 
CODEBASE 

S IZE- <max - KB > — the maximum allowable size foi the soft- 
ware archive file. "Kilobytes'* is the unit of measure. If SIZE 
is exceeded, then the software will not be downloaded. 
HREF=<URL> - poults to the archive to be downloaded. 
FILENAME»<string> — specifies a file contained within the 
same archive as the OSD. If the OSD is used as a stand-alone 
file, then this attribute is ignored. 
IMPLEMENTATION 
DEPENDENCY 

ACTION" (Assert I Install) - Assent means: Ignore this 
SOFTPKG entirely if the dependency is not already present on 
the client's machine. Install means: If the dependency is not 
already present on the client's machine, go get it, then install 
it, so that the SOFTPKG has all the pieces it needs. 
SOFTPKG, IMPLEMENTATION 
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TABLE 1 -continued 



<NameSpace>Fred 's Software Company</NameSpace> 
Thus the use of namespaces avoids version mismatches 
among software packages. 
A namespace is analogous to a directory in a file system, 
s such as implemented in the Windows family of operating 
systems, in that installing applications in different directo- 
ries provides isolation for the applications. Previously a 
namespace was global to all applications installed on a 
system so that all files and components in the namespace 
10 were accessible by the applications. The global nature of 
previous namespaces presents difficulties in naming files and 
components because an application programmer has to 
avoid common names to prevent potential conflicts with 
identically named files and components for another appli- 
15 cation installed in the same namespace. Installing the second 
of the two applications would likely cause one or both 
applications to fail, just as placing all files for all applica- 
tions installed on a computer into a single directory fre- 
quently causes conflicts between the applications. 
20 In the present invention, the presence of a namespace 
XML tag in the manifest file causes the package manager to 
associate the files and components of the corresponding 
application in the code store data structure with the unique 
namespace specified in the tag. When an application is 
25 executed, the package manager passes the associated 
namespace name to the computer's runtime environment so 
that any files and components installed in that namespace are 
visible to the application while files and components 
installed in other namespaces are not. Using the example 
30 XML tag above, Fred's CoolestApp is associated with a 
namespace called "Fred's Software Company," would 
execute in the "Fred's Software Company" namespace, and 
have access to any files or components installed in the 
"Fred's Software Company" namespace. Similarly, an XML 
35 tag for Bob's identically named "CoolestApp" would 
specify "Bob's Software Company" as the namespace, 
execute in the "Bob's Software Company" namespace, and 
have access to any files or components installed in the 
"Bob's Software Company" namespace. Neither Bob's 
40 CoolestApp nor Fred's CoolestApp can access a common 
component or file installed in the other's namespace. 
Therefore, because of the isolation that namespaces provide, 
both Fred and Bob are assured their applications will func- 
tion correctly even though identically named and having 
45 common components or files, and that the applications will 
continue to function correctly irregardless of the number of 
CoolestApps using the same components or file which may 
— ^ — be installed on the computer. 

„ , . , j j | VXjfT Continuing with the distribution of Fred's Software Com- 

The OSD vocabulary can be used in a stand-alone XML CoolestApp, the manifest file in a first exemplary 

mifest file to declare the dependencies between different ' m sectkm fa storcd separatdy from F ^ 

distribution unit at http://www.fsc.com/coolestapp.osd. The 
corresponding distribution unit is stored in a cabinet file at 
http://www.fsc.org/coolestapp.cab. The CoolestApp 's 
55 dependency on the components of the earlier CoolApp is 
indicated with a "DEPENDENCY" tag and refers the pack- 
age manager to the CoolApp manifest file at http:// 
www.fisc.org/coolapp.osd (not shown). The CoolApp mani- 
fest file directs the package manager to the location of the 
60 distribution unit for the CoolApp. 



Parent of 
Element 
Attributes 



Child of 
Element 
Attributes 
Child of 
Parent of 

Element 
Attribute 
Child of 
Element 
Attributes 

Child of 
Element 
Attributes 
Child of 
Element 
Attributes 



Child of 
Element 
Attributes 

Child of 
Element 
Attributes 
Child of 
Element 
Attributes 

Child of 
Element 
Attributes 



Child of 
Parent of 

Element 
Content 
Child of 
Element 
Attributes 
Child of 



SOFTPKG 
DISKS IZE 

VALUE-<KB-number> - approximate minimum number 
of bytes of disk space required by this implementation. "Kilo- 
bytes" is the unit of measure, 
IMPLEMENTATION 
IMPLEMENTATION 
None Supported 
SOFTPKG 

CODEBASE, DEPENDENCY, DISKSIZE, EMPLTYPE, 

LANGUAGE, OS, PROCESSOR, VM 

EMPLTYPE 

VALUE»<string> - the type of the implementation. 

IMPLEMENTATION 

LANGUAGE 

VALU E= <s tring> - uses language codes as specified in 
ISO 639. 

IMPLEMENTATION 

LICENSE 

HREF 

SOFTPKG 

MEMSIZE 

VALUE -<KB-number> approximate minimum number of 
bytes of memory required by this implementation during 
execution. "Kilobytes" is the unit of measure. 
IMPLEMENTATION 
OS 

VALUE- <string> -- see Appendix B for a list of possible 
values. 

IMPLEMENTATION 
OSVERSION 
VALUE-<string> 
OS 

PROCESSOR 

VALUE=<string> - see Appendix B for a list of possible 
values. 

IMPLEMENTATION 
SOFTPKG 

HREF - indicates the Web page associated with a software 
distribution. Optional. 

NAME-<string> -- the name of the distribution. For a given 

SOFTPKG, this attribute should be a unique identifier. The 

client can use NAME to distinguish one SOFTPKG from all 

others. A software package's "friendly-name" is specified by 

using the TITLE element 

VERSION-<string> 

DEPENDENCY 

ABSTRACT, CODEBASE, IMPLEMENTATION, 

DEPENDENCY, TITLE 

TITLE 

<string> 

SOFTPKG 

VM 

VALUE 

IMPLEMENTATION 



manifest file to declare the depend* 
software components for different operating systems and 
languages. The OSD file provides instructions that can be 
used to locate and install only the required software com- 
ponents depending on the configuration of the target 
machine and what software is already present. The OSD 
formatted manifest file also can be embedded in an archive 
file, such as a Java Archive (JAR) file, or a composite, 
compressed file, such as a cabinet (.CAB) file, that contains 
the component's distribution unit to form a distribution unit 
file. 

Additionally, the manifest file can specify an XML tag, 
"namespace," that causes the package manager to isolate 
software packages from one another even if the same 
component is used by multiple packages: 

<JAVA> 



65 



<SOFTPKG NAME="com.fsc.www.coolestapp M VERSION-" 1,0,0,(T> 
<fnTLE>CoolestApp </TTTLE> 

<ABSTRACT>CoolestApp by Fred's Software Company</ AB- 
STRACTS 
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-continued 



dJCENSE HREF="http://www.fec.conYcool«tfl^ 

<! — FSC's CoolcstApp is implemented in native code -> 

IMPLEMENTATION 5 

<OS VALUE" "WinNT'xOSVERSION VALUE«>"4,0A07>VOS> 

<OS VALUE-"Win95 , 7> 

PROCESSOR VAUJE-"x867> 

<LANOUAOE VALUE="en7> 

<CODEBASE HREFo M http7Avww.fi5c.org/coole5topp.cab"/> 

<! — CoolcstApp needs CoolerApp -> 10 

<DEPENDENCY > 

cCODEBASE HREF= M http^Affww.f6c.org^coolapp.oscr7> 
</DEPENDENCY> 
</IMPLEMENTATION> 
</SOFTPKG> 
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Had the CoolApp manifest file been stored in a cabinet 
distribution unit file along with the CoolApp components, 
the location of the distribution unit file would have been 
http://www.f5c.org/coolapp.cab. ^ 

In a second exemplary embodiment of the invention for 
purposes of this section, components contained in a distri- 
bution unit file are caused to be installed by OSD tags 
embedded on a Web page. If Fred's Software Company's 
Web page requires additional software to be downloaded 
and installed for viewing the page, FSC can use the OSD 
vocabulary within HTML commands to have the user's 
browser download the necessary components as shown in 
the two examples below. 

30 



<OBJECT CLASSrD=-clsid:9DBAFCCF-592F-101 B-85CE- 
00608CEC297B 

VBRSION=-l,0 > O t O" 

CODEBASE-"httpy/www.£sc.com/coolestapp.osd" 
HEIGHT-100 WIDTH-200> 
</OBJECT> 
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<APPLET code-myappleUlass id-coolestapp width-320 heighU-240> 
<PARAM NAMB=useslibrary VALUE- M coalesUpp"> 
<PARAM NAMEouscslibraryvereion VALUE="1,0 > 0,0 , *> 
<PARAM NAME-useslibrarycodebase VALUE- 40 
"http ://www.ffic.com/coo]eetapp.osd 

"> 

</APPLET> 



The HTML <0BJECT> or <APPLET> tag informs an 45 
OSD-aware client browser, such as Microsoft Explorer 4, 
that there is additional software required to view the Web 
page. The browser invokes the package manager to execute 
the software package if it is already installed or to install it 
if not. If not already installed, the package manager instructs 50 
the browser to download the distribution file unit and 
proceeds with the installation as described in the previous 
section. The "CODEBASE" element in <OBJECT> and the 
"useslibrarycodebase" tag in <APPLET> can point to the 
manifest file or to the distribution unit file. 55 

In a third exemplary embodiment of the invention for 
purposes of this section, a distribution unit file is used to 
automatically distribute software from Fred's Software 
Company's server to the user's computer. This automatic 
distribution across a network employs "channels" to which 60 
the user subscribes to automatically "push" software com- 
ponents through a client agent such as a browser. The 
channel is described using a Channel Definition Format 
(CDF) which is also based on XML. A CDF file uses the 
OSD elements to inform a CDF- aware client agent as to 65 
what software components should be downloaded and 
installed. 



cCHANNEL HREF="bttpyAvww.f5C.com.iatropagc.htm M > 
<SELF= u ht^^/www.fjsc.com/softwarc.cdr/> 
<TITLE>A Software Distribution Channel </TTTLE> 
<SOFTPKG 

HREF="http ^/www.fsc com/aboutsoftwaichtm" 

AUTOINSTALL-"y«'' 

NAME="{D27CDB6E-AE6D-llCF-96B8-4445535400O0}" 
VERSION="1,0 1 0,0"> 
<IMPLEMENTATION> 

<OS VALUE-" WinNT'xOS VERSION VALUE-* t 4,0,0,07>/OS> 
<OS VALUE= - Win957> 
PROCESSOR VALUE--x86"/> 

<CODEBASE HREF="http://www. fec.com/coolestapp .cab"/> 
</lMPLEMENTATION> 
</SOFTPKG> 
</CHANNEL> 



This section has described a particular implementation of 
the package manager which is directed to install software by 
OSD elements embedded in an XML document. The pro- 
cessing of a manifest file described in previous section when 
written as XML document is described. In addition, alternate 
embodiments in which a separate XML document resides on 
a Web page to direct a browser to invoke the package 
manager to install a software package is also described in 
this section. 

Conclusion 

A software package manager has been described which 
manages the installation, execution and uninstallation of 
software packages acquired through various media. The 
software manager uses a manifest file, a distribution unit, 
and a code store data structure to accomplish its functions. 
Although specific embodiments have been illustrated and 
described herein, it will be appreciated by those of ordinary 
skill in the art that any arrangement which is calculated to 
achieve the same purpose may be substituted for the specific 
embodiments shown. This application is intended to cover 
any adaptations or variations of the present invention. 

For example, those of ordinary skill within the art will 
appreciate that the file and data structures described herein 
can be easily adapted to future distribution media. 
Furthermore, those of ordinary skill within the art will 
appreciate that future extensible languages which are plat- 
form and operating system independent can be used to direct 
the software package managers actions. 

The terminology used in this application with respect to is 
meant to include all hardware and software platforms. 
Therefore, it is manifestly intended that this invention be 
limited only by the following claims and equivalents 
thereof. 

We claim: 

1. A computerized method for installing a software pack- 
age on a computer over a network with reference to a code 
store data structure tracking whether components of soft- 
ware packages are installed on the computer, comprising: 
downloading to the computer from the network a manifest 
file that describes at least one distribution unit for a 
software package, wherein the manifest file specifies a 
non-local location for acquiring a distribution unit 
when not present on the computer; 
resolving software dependencies on the computer for the 
software package by consulting the code store data 
structure and the manifest file to identify at least one 
distribution unit indicated in the manifest file as 
depended on by the software package but not yet 
installed on the computer, 
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responsive to determining that the code store data struc- 
ture tracking whether components of software pack- 
ages are installed indicates the identified depended on 
distribution unit is not installed on the computer, 
acquiring from the network the at least one identified 
distribution unit for the software package from the 
non-local location specified in the manifest file; 

causing installation of the software package on the com- 
puter; and 

updating the code store data structure on the computer to 
indicate that the at least one identified distribution unit 
indicated in the manifest file as depended on by the 
software package and acquired from the non-local 
location specified in the manifest file is installed on the 
computer. 

2. The method of claim 1, wherein resolving the software 
dependencies comprises: 

acquiring, for each of the software dependencies in turn, 
a dependency manifest file that describes a dependency 
distribution unit for a dependency software package; 

resolving software dependencies for the dependency soft- 
ware package as specified by the dependency manifest 
file; 

acquiring the dependency distribution unit for the depen- 
dency software package; 

extracting components in the dependency software pack- 
age from the dependency distribution unit into a direc- 
tory on the computer; 

causing the installation of the dependency software pack- 
age on the computer; and 

updating the code store data structure on the computer 
with information from the dependency manifest file 
pertaining to the dependency software package. 

3. The method of claim 1, wherein the. software depen- 
dencies are nested so that resolving the software dependen- 
cies is processed recursively. 

4. The method of claim 1 further comprising: 
locating the components for the software package using 

the code store data structure when execution of soft- 
ware in the software package is requested. 

5. The method of claim 1 further comprising: 
modifying the code store data structure to reflect removal 

of the software package when uninstallation of the 
software package is requested; and 
deleting each component for the software package when 
the code store data structure indicates no other software 
package uses the component. 

6. The method of claim 1, wherein the manifest file 
specifies a directory into which the components of the 

, software package are extracted, the method further compris- 
ing: 

extracting components in the software package from the 
at least one acquired distribution unit into the directory. 

7. The method of claim 1, wherein the distribution unit is 
a compressed file. 

8. The method of claim 1, wherein the manifest file and 
the distribution unit comprise a distribution unit file and the 
manifest file and the distribution unit are acquired by 
extracting each from the distribution unit file. 

9. The method of claim 8, wherein the distribution unit file 
comprises a dependency distribution unit. 

10. The method of claim 8, wherein the distribution unit 
file comprises a plurality of distribution units. 

11. The method of claim 8, wherein the distribution unit 
file is a compressed file. 
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12. The method of claim 1, wherein the manifest file and 
the distribution unit are distributed on a computer-readable 
medium. 

13. The method of claim 1, wherein the components in the 
software package and the software dependencies comprise 
native code components. 

14. The method of claim 1, wherein the components in the 
software package and the software dependencies comprise 
Java classes. 

15. The method of claim 1, wherein the components in the 
software package and the software dependencies comprise a 
mixture of native code components and Java classes. 

16. The method of claim 1, wherein extracting the com- 
ponents comprises: 

copying the components from the distribution unit into a 

file structure having a file directory; 
updating the file directory with information about each 

component in the file; and 
storing the file structure into the file directory on the 

computer. 

17. The method of claim 1, wherein the code store data 
structure resides in an existing system data structure and the 
step of updating the code store data structure comprises the 
step of interfacing with an existing system data structure 
manager. 

18. The method of claim 1, further comprising: 
determining when a component in the software package 

already exists on the computer; 
comparing the versions of the components; and 
updating the code store data structure with the location for 

the component which is the later version. 

19. The method of claim 1 wherein 

at least one software dependency specifies a plurality of 

components via a single name; and 
the code store data structure is operable to indicate, via the 

single name, whether the plurality of components are 

installed. 

20. A computerized method for managing software pack- 
ages on a target computer, comprising the steps of: 

acquiring, by the target computer, a manifest file that 
describes at least one distribution unit for a software 
package, wherein the manifest file is Open Software 
Description format; 

resolving software dependencies for the software package 
as specified by the manifest file by identifying at least 
one distribution unit depended on by the software 
package but not yet installed on the target computer; 

acquiring the at least one identified distribution unit for 
the software package; 

extracting components in the software package from the 
at least one acquired distribution unit into a directory 
on the target computer; 

causing the installation of the software package on the 
target computer; and 

updating a code store data structure on the target computer 
with information from the manifest file pertaining to 
the software package. 

21. A computerized method for managing software pack- 
ages on a computer comprising the steps of: 

acquiring, by the computer a manifest file that describes 
at least one distribution unit for a software package; 

resolving software dependencies for the software package 
as specified by the manifest file by identifying at least 
one distribution unit depended on by the software 
package but not yet installed on the computer; 
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acquiring the at least one identified distribution unit for 

the software package; 
extracting components in the software package from the 

at least one acquired distribution unit into a directory 

on the computer, 
causing the installation of the software package on the 

computer; 

updating a code store data structure on the computer with 
information from the manifest file pertaining to the 
software package; 

determining if the manifest file specifies that the software 
package cannot share components with a software 
package previously installed on the computer; and 

isolating the components in the software package by 
associating the components in the code store data 
structure with a unique execution space specified by the 
manifest file. 

22. A computer-readable medium having computer- 
executable instructions to cause a client computer to install 
a software package via a network on a computer with 
reference to a code store data structure tracking whether 
components of software packages are installed on the client 
computer by performing the following: 

downloading to the client computer from the network a 
manifest file and a distribution unit for a software 
package described by the manifest file from a server 
computer; 

resolving software dependencies on the client computer 
for the software by consulting the code store data 
structure tracking whether components of software 
packages are installed on the client computer and the 
manifest to identify at least one distribution unit indi- 
cated in the manifest file as depended on by the 
software package but not yet installed on the client 
computer, wherein the manifest file specifies a non- 
local location for acquiring the distribution unit when 

* not present on the client computer; 

respoasive to determining that the code store data struc- 
ture tracking whether components of software pack- 
ages are installed indicates the identified depended on 
distribution unit is not installed on the client computer, 
acquiring from the network the at least one identified 
distribution unit for the software package from the 
non-local location specified in the manifest file; 

causing the client computer to install the software pack- 
age; and 

updating the code store data structure in the client com- 
puter to indicate that the at least one identified distri- 
bution unit indicated in the manifest file as depended on 
by the software package and acquired from the non- 
local location specified in the manifest file is installed 
on the client computer. 

23. The computer- readable medium of claim 22, wherein 
resolving the software dependencies comprises: 

acquiring, from a server computer for each of the software 
dependencies in turn, a dependency manifest file that 
describes a dependency distribution unit for a depen- 
dency software package; 

resolving software dependencies for the dependency soft- 
ware package as specified by the dependency manifest 
file; 

extracting components in the dependency software pack- 
age from the dependency distribution unit into a direc- 
tory on the client computer; 

causing the client computer to install the dependency 
software package; and 
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updating the code store data structure on the client com- 
puter with information from each dependency manifest 
file pertaining to the dependency software package. 

24. The computer-readable medium of claim 22, wherein 
5 the software dependencies are nested so that the client 

computer processes resolving the software dependencies 
recursively. 

25. The computer-readable medium of claim 22, wherein 
the code store data structure resides in an existing system 

10 data structure managed by an operating system in the client 
computer and updating the code store data structure com- 
prises interfacing with the operating system. 

26. A computer-readable medium having stored thereon a 
code store data structure for tracking whether components of 

15 software packages are installed on a computer, the data 
structure comprising: 

a name field containing data representing a name of a 
distribution unit for a software package installed on the 
computer; 

20 a unit version field containing data representing a version 
for the distribution unit represented by the name field; 
a component field containing data representing a list of 
components in the distribution unit represented by the 
M name field; 

a location field containing data representing a location, if 
any, on the computer at which components in the list 
can be found; and 
a source field containing data representing a source from 
30 which the distribution unit represented by the name 
field can be acquired by the computer, wherein the 
source field is operable to specify a non-local location. 

27. The computer-readable medium of claim 26, wherein 
the component field further comprises a component name 

35 field for each component in the distribution unit. 

28. The computer-readable medium of claim 26, wherein 
the data structure further comprises: 

a component version field containing data representing a 
version for a component in the list represented in the 
40 component field; and 

a component type field containing data representing a data 
type for the component represented in the component 
version field. 

29. The computer-readable medium of claim 26, wherein 
45 the data structure further comprises a digital signature data 

field containing data representing a digital signature affixed 
to the distribution unit. 

30. A computer system comprising: 
5Q a processing unit; 

a system memory coupled to the processing unit through 
a system bus; 

a computer-readable medium coupled to the processing 
unit through the system bus; and 
55 a software package manager executed from the computer- 
readable medium by the processing unit, wherein the 
software package manager comprises 
a software installation function that causes the process- 
ing unit to store components comprising software 
60 and contained in a distribution unit onto a computer- 

readable medium as directed by a manifest file, to 
identify and acquire at least one distribution unit 
listed in the manifest file depended on by the soft- 
ware that a code store data structure indicates is not 
65 yet installed from a non-local location listed in the 

manifest file, to install the software, and to update 
the code store data structure stored on a computer- 
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readable medium with information contained in the 
manifest file, 

a software execution function that causes the process- 
ing unit to locate the appropriate components using 
the code store data structure when the processing 
unit is instructed to execute the software, and 

an uninstallation function that causes the processing 
unit to remove the components from the computer- 
readable medium and to modify the code store data 
structure when the processing unit is instructed to 
un install the software. 

31. The computer system of claim 30, further comprising 
a transport medium coupled to the system bus and further 
communicatively coupled to a server computer, and wherein 
the software installation function causes the processing unit 
to acquire the manifest file and the distribution unit from the 
server computer through the transport medium. 

32. A computer-readable medium having computer- 
executable instructions to cause a client computer to perform 
a method comprising: 

downloading a manifest file and a distribution unit for a 
software package described by the manifest file from a 
server computer, wherein the manifest file is Open 
Software Description format; 

resolving software dependencies for the software package 
as specified by the manifest file by identifying at least 
one distribution unit depended on by the software 
package but not yet installed on the client computer; 

acquiring, by the client computer, the at least one iden- 
tified distribution unit for the software package; 

extracting components in the at least one acquired soft- 
ware package from the distribution unit into a directory 
on the client computer; 

causing the client computer to install the software pack- 
age; and 

updating a code store data structure in the client computer 
with information from the manifest file pertaining to 
the software package. 

33. A computer- readable medium having computer- 
executable instructions to cause a client computer to perform 
a method comprising: 

downloading a manifest file and a distribution unit for a 
software package described by the manifest file from a 
server computer; 

resolving software dependencies for the software package 
as specified by the manifest file by identifying at least 
one distribution unit depended on by the software 
package but not yet installed on the client computer; 

acquiring the at least one identified distribution unit for 
the software package by the client computer; 

extracting components in the software package from the 
at least one acquired distribution unit into a directory 
on the client computer; 

causing the client computer to install the software pack- 
age; 

updating a code store data structure in the client computer 
with information from the manifest file pertaining to 
the software package; 

determining if the manifest file specifies that the software 
package cannot share components with a software 
package previously installed on the client computer; 
and 

isolating the components in the software package by 
associating the components in the code store data 
structure with a unique execution space specified by the 
manifest file. 
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34. A computer-implemented method for distributing soft- 
ware to a computer having a data structure for tracking 
whether software components arc installed on the computer, 
the method comprising: 

5 downloading to the computer a software package, 
wherein the software package comprises a dependency 
list indicating one or more items depended upon by the 
software package, wherein at least one of the items on 
the dependency list is not contained in the software 

10 package, and the software package indicates a remote 
location from which the item can be obtained; 
consulting the data structure to determine that at least one 
of the items on the dependency list is not installed on 
the computer; 

is responsive to determining that the item in the dependency 
list is not installed on the computer, downloading the 
item from the remote location specified in the software 
package; and 

updating the data structure to indicate that the down- 
20 loaded item is installed on the computer. 

35. The method of claim 34 wherein the consulting the 
data structure and downloading the item arc performed 
responsive to execution of software of the software package. 

36. A software installation system for installing software 
25 at a computer, the software installation system comprising: 

a data structure indicating whether or not a software 

package is installed at the computer; 
a software package receiver for receiving a software 
package comprising a dependency list indicating one or 

30 more items depended upon by the software package, 
wherein at least one of the items on the dependency list 
is not contained in the software package, and the 
software package indicates a remote location from 
which the item can be obtained; 

35 a dependency resolver operable to consult the data struc- 
ture to determine that at least one of the items on the 
dependency list is not installed on the computer; 
a downloader responsive to the resolver and operable to 

4Q download the item from the remote location specified 
in the software package when it is determined that the 
item in the dependency list is not installed on the 
computer; and 
a data structure updater to update the data structure to 

4S indicate that the downloaded item is installed on the 
computer. 

37. The software installation system of claim 36 wherein 
the dependency resolver is operable to be invoked respon- 
sive to execution of the software of the software package. 

50 38. A computer- implemented method for installing a 
software package on a computer system, wherein the soft- 
ware package comprises a name and a list of software 
dependencies, and the computer system comprises a code 
store data structure indicating whether a software package 
55 has been installed, the method comprising: 

via the software package name, consulting the code store 
data structure to identify whether the software package 
is already installed on the computer system; 
responsive to determining the software package is not 
60 already installed on the computer system, consulting 
the list of dependencies and the code store data struc- 
ture to identify whether the dependencies are already 
installed on the computer system, wherein at least one 
of the dependencies indicates another software pack- 
65 age; 

responsive to determining the dependency that is a soft- 
ware package is not installed, acquiring a list of further 
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dependencies for the dependency that is a software 
package and consulting the list of the further depen- 
dencies and the code store data structure to identify 
whether the further dependencies are already installed 
on the computer system; and 
responsive to determining a dependency is not already 
installed on the computer system, acquiring the depen- 
dency from a location indicated in its respective soft- 
ware package. 
39. The method of claim 38 wherein the software package 

comprises a mixture of native code components and Java 

classes. 
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40. The method of claim 38 wherein the software package 
is distributed via a computer-readable medium. 

41. The method of claim 38 wherein acquiring dependen- 
cies is deferred until execution of the software is requested. 

42. The method of claim 38 wherein the list of depen- 
dencies specifies at least one item at a remote location. 

43. The method of claim 38 further comprising deleting 
installed software from the location indicated in the code 
store data structure when un installation is requested and the 
code store data structure indicates no other installed soft- 
ware depends thereoa 
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